Replace big JS dict with JSON parsing - #71250

Nice! This is huge for embedded crates!

It would be nice if this could include a statement of the schema of the index, that way rustup might be able to use it to provide rustup doc File for example

It's the same as before. But if you the schema anyway, I can send it to you?

Having it formally stated would be good. Parsing JSON in rustup is plausible, where running arbitrary javascript was not :D

Cool！However, is possible to minify the Json search index to reduce the file size?

No. That's something I've been working on for a long time and I was able to get some improvements, but nothing extraordinary. The best we can do for the moment is compressing the result (which I expect is done by the users wanting to host their own doc).

Google Chrome team gives an awesome video to explain why the JSON.parse is faster than the native Javascript object literal. Very impressive.
https://www.youtube.com/watch?v=ff4fgQxPaO0

I'm content with it as-is, though I'd prefer to see the JSON as a separate file if that's not a huge amount of work.

@GuillaumeGomez Have a ponder over my points in the review, and if you feel things are OK enough as-is, or that splitting the JSON into a separate file is too hard for now, then you have r=me.

@kinnison As I know, if we use search-index.json, then we need an extra step to load the JSON file via HTTP request, which brings no efficient, even worse than the current implementation.

That load could be deliberately done as an asynchronous operation, enabling the search box only when the load is complete, and that means the actual usable page load could be faster; but as I said, I'm happy if that doesn't happen in this PR.

This is what I tried at first, but you can't load a JSON file locally because of security concerns, meaning that we'd need an HTTP server when using local docs, which I'm strongly opposed to. So unfortunately, we're still forced to keep the JSON as a string in the same file...

Also, the problem here isn't the download of the file but the JS parsing (which is now kinda solved since there is almost no JS).

With agreement of @kinnison :

@bors: r=kinnison

📌 Commit b4fb306 has been approved by kinnison

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Tweak 'static suggestion code #71235

📌 Commit b4fb306 has been approved by kinnison

⌛ Testing commit b4fb306 with merge aeeae8925dcc1f8a1bb0062efd5d9ba61afd856a...

@bors retry (included in rollup)

☔ The latest upstream changes (presumably #71356) made this pull request unmergeable. Please resolve the merge conflicts.

@alecmocatta JSONP isn't really a solution, as it brings the problem we are trying to avoid in the first place - embedding data in script context.

Still, the search isn't immediately required on load (user likely won't interact with it withing first second anyway), so time to first paint could still be improved by not waiting on it. Possible solution might involve defer or async script attributes.

@Frizi Sorry, I was misinterpreting a comment upthread. I was meaning storing the search index as a file like:

callback(JSON.parse("{...}"))

which it turns out is exactly what this PR is doing!

@Frizi If you load a page with search query in the URL, search will kick in pretty early (but I'm nitpicking here :p).

@alecmocatta: Yes absolutely. Glad to see we're on the same page!